[UPDATE] AWS Elemental MediaConnectがSRT caller modeをサポートしました!
はじめに
清水です。本エントリでお伝えするアップデート情報はこちら!AWSの高品質ライブ動画伝送サービスであるAWS Elemental MediaConnectで従来までのSRT listenerモードに加えて、SRT callerモードもサポートするようになりました。(2022/09/19付でAWS What's Newにポストされたアップデート情報となります。)
MediaConnectでは2021年3月の段階でSecure Reliable Transport (SRT)プロトコルをサポートしていましたが([UPDATE] AWS Elemental MediaConnectがSRTプロトコルをサポートしました! | DevelopersIO)、このときはlistenerモードのみのサポートでした。今回のアップデートではSRT callerモードをサポートし、また従来までのlistenerモードと同じくsourcesとoutputsの双方で利用可能となります。listener to caller/caller to listener/caller to caller/listener to listenerそれぞれのsource/outputの組み合わせがサポートされることとなりますね。
本エントリでは、sourceにSRT callerを使ったMediaConnectによる映像伝送の動作を確認してみました。
MediaConnectのSRT caller modeを使ってみた
それでは実際にMediaConnectのSRT caller modeを使ってみたいと思います。以下の構成で動作確認をしてみました。構成が少し複雑ですが、 SRT callerの対になるSRT listenerにもMediaConnectを使いました。これが(1)のMediaConnectsrt-listener-flow
です。 srt-listener-flow
はsource、outputともにSRT listener modeとしています。なお、この映像の打ち上げ先となるこのstr-listener-flow
への入力には、OBS Studioを使いました。SRTで接続(映像の打ち上げを)しています。
(2)のMediaConnectsrt-caller-flow
が今回のアップデートの本題ですね。このsrt-caller-flow
ではsourceをSRT caller modeとしています。またこのoutputを入力として、(3)のMediaLive Workflowを作成します。MediaLive WorkflowではMediaLiveのInput/Channelリソースのほか、MediaPackageならびにCloudFrontのリソースも作成します。打ち上げた映像がつのMediaConnectを介して伝送されてMediaLiveの入力となり、最終的にMediaPackageをオリジンに持つCloudFront経由で視聴確認を行うかたちとなります。
1. MediaConnect SRT listener flowの作成
まずはMediaConnectのSRT listener flow「srt-listener-flow
」を作成します。MediaConnectのマネジメントコンソール、[Create flow]ボタンから進みます。
DetailsのNameでは「srt-listener-flow
」と入力、SourceのSource typeでは「Standard source」を選択します。SourceのNameは「srt-listener-source
」としました。Protocolでは「SRT listener」を選択します。(ここではSRT callerではありません。)
Source descriptionはわかりやすく「SRT listener Source」とします。Allowlist CIDR blockは映像の打ち上げ元となるOBS Studioが稼働している環境のIPアドレスをCIDR表記で入力しました。Inbound portは「5083
」としています。Maximum bitrateは10Mbps(「10000000」)、Minimum latencyは2000ms(「2000」)としました。暗号化設定は行わずに進めます。
srt-listener-flow
のFlowとSourceが作成できました。
続いてこのsrt-listener-flow
のOutputを作成します。Outputsタブの[Add output]ボタンから進みます。
Nameは「srt-listener-output
」としました。Output typeでは「Standard output」を選択、Protocolでは「SRT listener」を選択します。(ここもまだSRT callerではありません。)Descriptionに「SRT listener Output」と入力、Minimum latencyは2000ms(「2000」)、Portは「5079
」とします。
CIDR allow listの項目ですが、この段階ではまだsrt-listener-output
へ接続するSRT caller(MediaConnectのsrt-caller-flow
)を作成していないため、IPアドレスも定まっていません。ここでは仮の入力値として、先ほどstr-listener-source
作成時と同じIPアドレスを指定しておきました。(空欄で進めることができなかったため、仮で指定しておいても問題ないIPアドレスとして指定しています。のちほど変更します。)
srt-listener-flow
のOutput、srt-listener-output
も作成できました。このsrt-listener-flow
のIPアドレス(より具体的にはsrt-listener-output
のIPアドレス)とsrt-listener-output
のポート番号はのちほどSRT callerとなるsrt-caller-source
の作成時に使用しますので控えておきます。ここで言えば、IPアドレス35.XXX.XXX.56
とポート番号5079
ですね。
2. MediaConnect SRT caller flowの作成
続いて、今回のアップデートの本題となる、SRT caller modeを使ったMediaConnect flow「srt-caller-flow
」を作成していきます。先ほどと同様、MediaConnectのマネジメントコンソール、[Create flow]ボタンから進みます。
DetailsのNameでは「srt-caller-flow
」と入力、SourceのSource typeでは「Standard source」を選択します。SourceのNameは「srt-caller-source
」としました。Protocolでは「SRT caller」を選択します。
Source descriptionはわかりやすく「SRT caller Source」としました。Source listener addressで、SRT callerの対となるSRT listenerのIPアドレスもしくはドメイン名を指定します。今回は先ほどのsrt-listener-flow
のOutputsrt-listener-output
のIPアドレス「35.XXX.XXXX.56
」を指定しました。(CIDR表記ではない点に注意しましょう。)Source listener portも同様に「5079
」を指定します。Maximum bitrateは10Mbps(「10000000」)、Minimum latencyは2000ms(「2000」)としました。Steam IDならびに暗号化設定は行わずに進めます。
srt-caller-flow
のFlowとSourceが作成できました。OutputについてはMediaLive側のWorkflowで作成しますので、MediaConnectのマネジメントコンソールからの操作はここでは行いません。
ただこの段階で、「1. MediaConnect SRT listener flowの作成」で作成したSRT listener flow srt-listener-flow
のOutputsrt-listener-output
のCIDR allow listの更新を行っておきましょう。この「2. MediaConnect SRT caller flowの作成」で作成したsrt-caller-flow
のIPアドレス(Public Outbound IP addressやsrt-caller-source
のInbound IP addressとして表示されているもの)が、srt-listener-output
への接続に使われるわけですので、これをsrt-listener-output
のCIDR allow listのIPアドレスとします。今回なら「35.XXX.XXX.222/32
」となります。
3. MediaLive Workflowの作成
SRT listenerなMediaConnect flowならびにSRT callerなMediaConnect flowが作成できました。続いて、SRT callerをsourceとするMediaConnect flowの出力先となるMediaLive workflowを作成していきます。MediaLiveのマネジメントコンソール、[Create workflow]ボタンから進みます。
Workflow nameは「srt-medialive-workflow
」としました。MediaLive channel classは「SINGLE_PIPELINE」としています。IAMロールを適切に設定して[Next]で進みます。
Input typeは「MediaConnect」を選択します。「create a new Input」として、MediaConnect flowsの選択で先ほど作成したsrt-caller-flow
を選択します。
OutputはMediaPackageを選択しました。検証目的ですので「720p30」のみの出力としています。
「Review and create resources」の画面で、Workflow Wizardでの作成内容を確認して、[Create workflow resources]でリソースを作成します。
最終の確認ダイアログです。[Create workflow resources]で進みます。
MediaLive Workflowが作成できました。
MediaConnect側、srt-caller-flow
を確認してみましょう。OutputsにMediaLiveが追加されていますね。
4. 映像を打ち上げて動作確認
AWS側リソースの作成ができました。映像を実際に打ち上げる前に、各リソースをStartさせていきます。作成したのと同じ順でStartさせていきましょう。
まずはMediaConnect srt-listener-flow
をStartさせます。
続いて、MediaConnectのsrt-caller-flow
のStartです。
そしてMediaLive Workflow srt-medialive-workflow
をStartさせます。(なおあとから確認できたのですが、MediaLive WorkflowのStart/StopはMediaConnect Flowにも連動するようですね。今回で言えば、srt-caller-flow
のStart/Stopはせずとも、srt-medialive-workflow
のStart/Stopのみの操作で完結するかと思います。)
AWS側の各リソースのStartができたら、OBS StudioでMediaConnectsrt-listener-flow
のsrt-listener-source
に映像を打ち上げます。OBS Studioの配信先設定でsrt://[srt-listener-sourceのInboud IP address]:[ポート番号]
を指定します。今回であればsrt://35.XXX.XXX.56:5083
となります。
打ち上げ後、映像を視聴してみましょう。今回はHLSでの視聴としました。視聴先のURLはMediaLive Workflow srt-medialive-workflow
の「MediaPackage HLS endpoint」のリソースから参照できます。リンク先となっている「srt-medialive-workflowHLSEndpoint
」をクリックしてMediaPackageのマネジメントコンソールに遷移します。エンドポイントへCloudFront経由でのアクセスとしたいため、「CloudFront URL」の項目を確認します。
PlayerはmacOS上のSafariブラウザとしました。確認した「CloudFront URL」にSafariからアクセスします。問題なく視聴できていますね!
MediaConnect FlowのそれぞれのSourceのメトリックも確認しておきましょう。srt-listener-flow
(srt-listener-source
)ならびにsrt-caller-flow
(srt-caller-source
)の双方で、映像が伝送されていることが確認できます。
まとめ
AWS Elemental MediaConnectで新たにサポートされたSRT caller modeについて、Sourceに指定して実際に動作を確認してみました。AWS Elemental MediaLive含め、AWS Elementalなサービスは多様な入出力フォーマットに対応していることが特徴です。例えばMediaLiveでも、InputにRTMP (push)のほかRTMP (pull)も利用可能になっていますね。今回のMediaConnectのSRT caller modeサポートもこの1つであると言えるかと思います。
MediaConnectもリリース当時はRTP、RTP-FEC、そしてZixi pushの3つのプロトコルのサポートのみでしたが、その後Zixi pull、RIST、SRT listener、Fujitsu-QoSと続々とサポートするプロトコルを増やしていきました。今後も主要なプロコルへの対応が期待できそうです!